前言

在《刀劍神域 (SAO)》裡，整個遊戲世界的生死都綁在系統的「規則書」上。
規則決定玩家能不能登出、戰鬥限制、甚至是「死了就真的死了」這種致命條款。
如果規則本身設錯，不管桐人再怎麼拼命，也救不了所有人。

雲端世界其實也一樣。
我們用 Infrastructure as Code (IaC) 來定義伺服器、資料庫、S3 bucket、VPC……就像寫下一份「世界設定」。
IaC 的好處是自動化、快速、可複製；壞處是——只要你在設定裡漏掉一個安全鎖，全世界的環境都會跟著暴露。

這就是 tfsec 出場的地方。
它的任務不是等房子蓋好才檢查，而是在「藍圖階段」就先審查，避免危險設定被帶上線。

1. 為什麼IaC要檢查？

在傳統網管時代，錯誤通常是「單點」：

• 忘了關一個防火牆 port。
• 漏掉一個帳號的權限收回。

問題雖然麻煩，但至少影響範圍有限。

到了IaC時代，狀況完全不同。
IaC 就像 SAO 的規則書：一行設定 = 全域規則。

• 你在 Terraform 裡寫了 public-read，就不是一台機器出問題，而是整個 bucket 全世界可讀。
• 你少寫一條網路限制，整個 VPC 都暴露。

這就是為什麼 IaC 更需要安全檢查。
因為在這個模式下，「一次寫錯，所有人一起中槍」。

tfsec的角色，就是在規則生效之前，幫你掃一遍，確認沒有把世界設定寫成「大門永遠敞開」。

2. tfsec的角色：自動化規則審查員

在SAO世界裡，如果有個GM能在遊戲上線前，把規則書逐條審核，發現「死了就真的死了」這種條款，玩家應該會感謝到痛哭流涕吧。

tfsec 就是這樣的角色。

• 它讀的是 Terraform 檔案，不是程式碼。
• 它檢查的是配置裡的安全性，例如：
  • S3 bucket 是否設為公開存取。
  • Security Group 是否允許 0.0.0.0/0 全開。
  • 資料庫是否缺少加密設定。
• 結果不是模糊的報告，而是具體指出「哪裡錯了、為什麼危險、怎麼修正」。

換句話說，tfsec 幫你做的就是：
在雲端世界啟動前，先把規則書裡的致命漏洞劃掉。

3. 實戰範例：S3 bucket 的公開讀取

假設你有一個最簡單的 Terraform 設定：
先建立s3.tf，加入以下內容當作測試範例使用

resource "aws_s3_bucket" "example" {
  bucket = "my-example-bucket"
  acl    = "public-read"
}

對初學者來說，這行 public-read 可能只是方便測試：
「啊我只是想快速丟檔案，誰要偷看啊？」
但在雲端世界，這等於在規則書裡寫下：
「大門永遠打開，任何人都能進來隨便搬東西。」

這時候跑一遍 tfsec：

tfsec .

輸出會長這樣：

Result #1 HIGH No public access block so not blocking public acls 
────────────────────────────────────────────────────────────────────────────────────────────
  s3.tf:1-4
────────────────────────────────────────────────────────────────────────────────────────────
    1    resource "aws_s3_bucket" "example" {
    2      bucket = "my-example-bucket"
    3      acl    = "public-read"
    4    }
────────────────────────────────────────────────────────────────────────────────────────────
          ID aws-s3-block-public-acls
      Impact PUT calls with public ACLs specified can make objects public
  Resolution Enable blocking any PUT calls with a public ACL specified


Result #2 HIGH No public access block so not blocking public policies 
────────────────────────────────────────────────────────────────────────────────────────────
  s3.tf:1-4
────────────────────────────────────────────────────────────────────────────────────────────
    1    resource "aws_s3_bucket" "example" {
    2      bucket = "my-example-bucket"
    3      acl    = "public-read"
    4    }
────────────────────────────────────────────────────────────────────────────────────────────
          ID aws-s3-block-public-policy
      Impact Users could put a policy that allows public access
  Resolution Prevent policies that allow public access being PUT
.
.
.
以下略過

它不只告訴你哪裡錯，還給出「為什麼危險」與「如何修正」。
這種精準提示，比事後才發現資料外洩要仁慈太多了。

4. CI/CD 整合：規則書不能偷改

光靠本地跑 tfsec 還不夠。
因為總有人會想：「測一下方便啦，先 push 再說。」
結果危險設定還是會偷偷混進主分支。

這時候就需要把 tfsec 放進 CI/CD pipeline，讓每一次 Pull Request 都要過審。
就像在 SAO，如果有人想偷偷修改規則書，系統會自動跳出來警告：「這條款會害死所有玩家，禁止上線。」

在 .github/workflows/ci.yml 加上：

- name: IaC Security Scan (tfsec)
  uses: aquasecurity/tfsec-action@v1.0.3
  with:
    args: .

這樣，每次有人提交 IaC 變更，tfsec 都會自動掃描：

• 發現高風險設定 → PR 直接掛紅燈。
• 沒問題 → 才能順利合併。

這不只是檢查，而是一種 制度化的守門機制。
讓安全成為規則的一部分，而不是靠記憶。

tfsec與其他工具

tfsec 的定位，可以理解成 SAST（靜態應用安全測試）的 IaC 版本。
(在這篇有介紹到SAST，忘記的可以先回去看。)
它不跑實際的雲端環境，而是靜態讀取 Terraform 檔案，檢查常見的錯誤配置。

常見的檢查規則來自：

• CIS Benchmark（雲端安全的國際標準規範）
• 社群貢獻的最佳實踐

除了 tfsec，還有其他常見選擇：

• Checkov：支援更多格式（Terraform、CloudFormation、K8s YAML…）
• Terrascan：強調策略與合規檢查
• kics：支援廣泛 IaC 類型，偏向開源社群維護

所以，tfsec 適合用在「以 Terraform 為主」的專案；
如果團隊環境很雜（例如 Terraform + Kubernetes + CloudFormation），則可能會選擇 Checkov 或混用多種工具。

關鍵不在於用哪一套，而是要建立起：
配置檔和程式碼一樣，都要過安全檢查，才能進到主分支。

5. 總結

在《刀劍神域》裡，規則書決定了整個世界的生死。
寫錯一條，所有玩家都可能陷入危險。

雲端世界的 IaC 檔案也是一樣。
它決定了伺服器怎麼部署、S3 bucket 有沒有公開、資料庫有沒有加密。
只要一行設定錯誤，影響範圍不是一台機器，而是整個系統。

tfsec 的價值就在於：

• 在世界啟動前，先幫你掃過規則。
• 把致命錯誤擋在藍圖階段，而不是等上線後才手忙腳亂。
• 結合 CI/CD，讓安全檢查成為制度，而不是人品。

寫 IaC 有點像寫遊戲模組：一行就能決定整個世界的規則。
你可以蓋一座城堡，也可以不小心留下通往地獄的傳送門。

tfsec 就像在你按下「啟動伺服器」之前，先提醒一句：
「大門還沒鎖好，要不要再檢查一次？」

因為在雲端世界裡，沒有人想成為下一個被笑說：
「搜你的公司名就能挖到資料。」

從網管時代的「一台一台檢查」，到 IaC 時代的「一次配置全環境」，風險變得更大，但方法也更聰明。
DevSecOps 的精神就是：安全不能事後補救，而是要嵌在整個流程裡。